REMARKS 



Claims 1-8 and 34-49 are pending in this application. Claims 2-8 and 34-43 are rejected 
under 35 U.S.C. §112, second paragraph, as being indefinite. Each of these claims has been 
amended to address the rejections. 

Claims 1-8 and 34-49 are rejected under 35 U.S.C. §102(e) as being anticipated by Patent 
No. 6,282,522 Bl to Davis. 

Introduction 

The Office action cites the Davis reference for disclosing a virtual smart card database, a 
smart card emulator, and a pseudo card reader, all elements recited in the independent claims. Davis 
teaches using a physical smart card 5 to make purchases over a payment system utilizing the 
Internet. The specification in Davis does state that the functionality of the card may be 
"implemented in software on a client terminal, that is, the card may be a 'virtual' card." [col. 11, 
lines 13-14]. This is the only instance where the term "virtual card" is mentioned in Davis. The rest 
of the specification focuses on implementing a payment system using a physical smart card. 

But, the claims also recite a "virtual smart card database" and a "pseudo card reader 
module." Applicant asserts that Davis does not teach or disclose either of these elements. 
Although Davis describes various hardware components in an Internet payment system, such as a 
card reader, a payment server, a merchant server, among others, none of these hardware components 
anticipate under § 102(e) a pseudo card reader module (in contrast to a physical card reader) nor do 
they anticipate a virtual smart card database . 

Pseudo card reader module 

Davis clearly shows a physical smart card and a physical smart card reader, for example, as 
shown in Figures 4 and 16. By contrast, claim 1 requires "a pseudo card reader module" that is not a 
physical card reader. Support for this assertion is found at various places in the present 
specification. For example, Figure 3, introduced at page 16, states "System 250 dispenses with the 
need for card reader 210 and smart card 5." Further, page 17, second full paragraph, provides 
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"server 260 emulates the physical smart card through the use of pseudo card reader module 264, 
smart card emulator 266, hardware security module 268 and card database 270." Thus, no physical 
smart card or physical card reader is used. 

Further, claim 1 specifically requires "a pseudo card reader module that receives said smart 
card commands over said network and relays said commands to said smart card emulator." As 
described in the specification at page 19, final paragraph, a pseudo card reader module "is a software 
module that performs the functionality of a physical card reader so that emulation of a smart card is 
transparent to client code module 224." Thus, the claimed pseudo card reader module is software 
whereas Davis only discloses a physical card reader. 

The Office action alleges that a pseudo card reader module is shown at column 7 of Davis, 
but this section clearly discloses a physical card reader into which a physical card is inserted. 
Further, the citation to column 8 only discloses a physical security card. The citation to column 10 
only discloses physical stored value cards and security cards that can only be inserted into a physical 
card reader. The final citation to column 1 1 likewise only discloses a physical security card. 

Furthermore, Davis describes how its card reader must be physical, rather than a software 
module: a "card reader interface 24" includes software and hardware necessary for communications 
with a card reader as shown in Figure 1. It is described as having, for example, a contact interface in 
which signals from a microcontroller are routed to a number of metal contacts on the outside of the 
physical smart card which come in physical contact with similar contacts of a physical card reader. 
The reference describes contexts in which a cardholder "inserts his or her card into a card reader 
attached to a personal computer." (see e.g., col. 7, lines 6-21). This is one example of how the 
physical card reader is described in Davis. Therefore, the "pseudo card reader module" recited in 
the claims cannot be anticipated under § 102(e) by Davis. 

For all these reasons, it is respectfully submitted that Davis does not disclose "a pseudo card 
reader module" as required by claim 1, and it is requested that the rejection be withdrawn. 
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Virtual smart card database 



Claim 1 further requires "a virtual smart card database" were each record includes a virtual 
card identifier and a balance that corresponds to a single virtual smart card. An example of such a 
virtual smart card database is shown in Figure 4. The Office Action relies upon a citation to column 
10, but this section only discloses a payment server that manages the database 223. Database 223 is 
a transaction database (see column 14, line 9) that stores transaction records; it is not a database that 
includes records where each record corresponds to a virtual smart card having a balance. The 
citation to column 11 only discloses a processor card (another name for a smart card) that has a 
number of functions; this section does not disclose a virtual smart card database. The citation to 
column 13 discloses a payment module that logs results; this is not a virtual smart card database. 
The citation to column 16 refers to data from a smart card and a draw or request which is a software 
message; neither of these sections disclose a virtual smart card database. 

Therefore, Applicant asserts that the "virtual smart card database" is not anticipated under 
§ 102(e) by Davis. 

Smart card emulator 

Davis does not teach or suggest "a smart card emulator" as required by claims 1 and 41 
because there is no enabling description of a "smart card emulator" in Davis. The Final Office 
action states that any disclosure in a reference may serve as anticipatory prior art (Final Office 
action dated May 9, 2006, page 9). Specifically, the Office action asserts that ". . .any disclosure 
serves as prior art and the disclosure as part of the Davis description that other forms including a 
virtual card may also be one means of the invention (column 11, lines 10-14), establishes a virtual 
card as prior art within the disclosure of the invention and the description of functionality therein." 

Applicant maintains its position that the proper standard for a reference serving as a basis for 
anticipation is that the disclosure be enabling in order to be anticipatory. Section 2121.01 of the 
MPEP states that "the standard test is whether a reference contains an enabling disclosure," and that 
"mere naming or description of the subject matter is insufficient, if it cannot be produced without 
undue experimentation." Applicant believes that the brief mention of a "virtual card" in Davis falls 
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short of providing an enabling description of a "virtual smart card" as described and claimed in the 
present application and is not a suitable § 102(e) reference for anticipation. Recitation of this single 
phrase fails to enable a concept as complex as using software to emulate a smart card. 

Conclusion 

Because the Final Office Action has used a legally incorrect standard for anticipation, it is 
requested that the Final Action be withdrawn and that a new action be issued using the correct 
standard, or that a new search be performed. Applicant notes that pursuant to § 103(c)(1) since 
Davis is cited as a § 102(e) reference and is owned by the same Applicant of the present application, 
it may not be used to preclude patentability under § 103(a). 

Should the Examiner believe that a telephone conference would expedite the prosecution of 
this application, the undersigned can be reached at the telephone number set out below. 

Respectfully submitted, 
BEYER LAW GROUP LLP 

/Rupak Nag/ 
Rupak Nag 
Reg. No. 37,493 

P.O. Box 1687 

Cupertino, CA 95015-1687 

612-252-3335 
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